(Sun Microsystems, Inc.)(1997).iso/products/Cobb/ordlogo.gif)
By David C. Moss
In our February article on Designer/2000, we used the Process Modeller to create and refine a picture of a business process at our fictional firm, Frick & Frack Financial. Creating a process model is one of the first steps in designing a complete logical model of your business. A logical model consists of all the things your organization needs to do and the information needed to do them, even if you're doing those things without any automation. A complete logical model is the most effective way to determine the areas in your organization that would benefit most from automation.
In this article, we'll focus on another key element of a logical model, the function hierarchy. We'll explore what a function hierarchy is, how to gather the information to build your function hierarchy, and how to create and alter your function hierarchy using the Function Hierarchy Diagrammer in Designer/2000.
A function is something your organization does. The primary purpose of function modeling is for you to gain an understanding of what your organization does and then describe it in a way you and key people within your organization can agree upon.
Oracle's CASE*Method describes a function using a sentence, generally beginning with a verb, such as manage or maintain. The verb indicates some action that must be taken on an area within your organization, such as Financial Operations. For example, a function describing a department in your organization might be Manage Financial Operations, where Manage is the verb and Financial Operations is the noun. Similarly, a function describing a specific operation in your organization might be Maintain Customer Accounts.
Function hierarchy modeling involves determining and describing individual functions and then showing where they fit in your organization or application. Functions describe what needs to be done, not how it will be done. For example, "Send the red alert fax to the Loan Department" might describe the current way things are being done at Frick & Frack. But what if you've been asked to select the most efficient way to get the job done? If we change the previous function to "Communicate urgent status to the Loan Department," we now leave the systems designer some leeway to choose the most effective way to communicate the message.
In order to determine which functions should go into your hierarchy, and to complete this critical part of your organization's logical model, you need to ask questions in such a way that you'll get the answers you need to create an agreed-upon model. Perhaps more important, you need to ask the right people those questions! As always, Oracle's CASE*Method has a recommended approach.
In Oracle's CASE*Method, there are two complementary modeling approaches to creating a function hierarchy: top-down and bottom-up. In top-down modeling, you begin by determining the highest level of your organization--or your application--and describing it in a sentence. If you're describing the highest level in your organization, you may find that you can use your organization's mission statement as your top function.
To obtain the appropriate high-level functions, you need to perform one or more of what are known as directional interviews--where the highest-level executives affected by your application are asked such questions as, "Which operational areas are affected by this application?" "What are the key objectives of this application?" and "What must be included in this application for it to be a success?"
From this directional interview, you can perform top-down modeling that will result in functions that describe the mission of your organization or application and the major functional areas to be covered in the application. It is of great importance that the wording of the functions match the business terminology of your organization. It's also important for you to obtain and document agreement on the definitions of this business terminology--so someone isn't thinking customer when you're saying account.
To perform bottom-up modeling, you need to conduct in-depth interviews, where you can explore in more detail specific business areas that have been designated from the directional interviews. The majority of functions will come from your in-depth interviews, as opposed to directional interviews, where you'll collect only a handful. You can collect additional functions through business manuals, marketing manuals, and any other sources your organization may have at its disposal.
Once you've collected a number of functions, it's time to organize them into a coherent model so that the major players can reach an agreement and the application can move forward. One of the most popular techniques for organizing functions is known as a function hierarchy--a collection of functions, grouped similar to an organization chart or a family tree. Figure A shows an example of a function hierarchy in the Function Hierarchy Diagrammer of Designer/2000.
Most of the work to create a function hierarchy is in creating the content--the functions--and there is no way to do this except by sheer brain power from a group of people committed to achieving an agreed-upon outcome.
We believe your best approach is to first discover as many functions as you can from user interviews and business documentation, then write each function on a post-it note. In a work session, have your team members select seven or eight top-level functions (or business areas) and place them about eye-level on a wall, directly below the top function or mission statement. Next, have the group select what it believes are the functions necessary to carry out the business needs of each of those areas. Don't be afraid to move things around or create new high-level functions--after all, that's why you're using post-its! This process will take a few hours to several days, depending on the size of your project.
Once you've completed this hierarchy modeling process, you're ready to enter your new function hierarchy into the Diagrammer. After entering the hierarchy created during your work session, you can easily move functions around as you discover and refine more information about your organization.
The top two levels of your new function hierarchy show the major functional areas your application will cover. These high-level functions act as headings for the specific functions you'll add to fully describe your organization or application.
By the way, with the exception of the highest function in the model, each function should have at least one and not more than eight, and ideally seven, functions below it. Low-level, or elementary, functions are the exception. While it may seem arbitrary to use seven as the ideal number, keep in mind that the Function Hierarchy Diagrammer, like all modeling tools, is a means to convey your understanding to other humans. And the human brain can absorb only so much at one time. It's no coincidence that the creation of seven-digit phone numbers was based on psychological research in the 1950s--seven items is the optimum amount that the human brain can easily deal with at one time.
The Function Hierarchy also shows the scope of your application--the functions that you'll analyze, design, and build during the course of the project. All elementary functions that appear in the function hierarchy will be implemented, either automatically or manually, as an outcome of the project. On the other hand, if a function doesn't appear in the function hierarchy, it won't be implemented in your application. If a high-level function doesn't have at least one function under it, then the high-level function probably belongs under some other function.
Designer/2000's Function Hierarchy Diagrammer is a graphical way for you to represent your functions. As an added bonus, the elementary functions you create here can be used later by some of the components of Designer/2000 to directly create module definitions for your software application. You can then use these module definitions to generate working Developer/2000 applications. This is one of the ways Designer/2000 can help you leverage your time by building on your earlier work.
The Function Hierarchy Diagrammer is by far the easiest tool to use in Designer/2000. It allows you to enter high-level functions, group them, create new root functions, create and identify elementary functions, and move functions between different groups. And therein lies your challenge. As we've discussed, you'll do most of your work outside of the Function Hierarchy Diagrammer. The Diagrammer acts almost like a tape recorder once you've decided what to say. The same is not true for the Entity-Relationship Diagrammer, which we'll discuss next month in our article, "Entity-Relationship Modeling and Designer/2000."
Once you've entered the functions into the Function Hierarchy Diagrammer, how do you know when you're finished? Part of the answer depends on what stage of the project you're in. Let's assume you're trying to determine the scope of the application. The questions to ask include: Does this model contain all necessary functions for this application? Are there any unnecessary functions in the model? Can you group the functions together? Does everyone agree on the business terminology? Does everyone feel comfortable about moving forward based on this model? When you feel you've answered all the possible questions as fully as you can, it's time to finalize the hierarchy.
Function hierarchy modeling allows you to record, refine, and reach agreement on what your business does before you start creating Forms, Reports, Graphics, and Procedures. This can save considerable work down the road, because reaching agreement on the function hierarchy also means that you and your organization have reached agreement on the scope of your application-what's in and what's out. Now, when changes and additions begin popping up, it will be much easier to have an open discussion within your organization about how those changes will affect your application.
The remaining components in Designer/2000 for modeling the logical part of your application are the Entity-Relationship Diagrammer and the Matrix Diagrammer. We'll examine these in detail in future articles. We'll then move on to discuss the physical aspects of application development using the Database Design Wizard and the Applications Design Wizard in Designer/2000.
If youíd like to learn more about function hierarchy modeling, we suggest you read CASE*Method - Function and Process Modelling by Richard Barker and Cliff Longman (Oracle/ Addison-Wesley, 1992).
You can obtain Designer/2000 white papers and other collateral from Oracle Corporation via its fax-on-demand number, (703) 777-2216. This telephone number is for US and Canadian users only. A catalog of these papers is also available.
David Moss is a Managing Consultant with TrueNorth Consulting, Inc., an information management consultancy with offices in Portland, Oregon, and Bellevue, Washington. You can reach him by phone at (503) 220-1790 or by E-mail at truenrth@ix.netcom.com.
[Return to Index for Exploring Oracle Developer/2000 and Designer/2000 - March 1996]
Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.
(Sun Microsystems, Inc.)(1997).iso/products/Cobb/ord9603/eod9633a.gif){kind=link}